From artefact to asset: A better way to think about service blueprints
There’s a quiet assumption baked into current thinking around service design — that a “good” service blueprint is a finished one.
After more than a decade working across different organisations, I’ve come to the conclusion that it’s the opposite. You shouldn’t aim to finish your service blueprint at all, because the moment you do, it stops being useful.
In today’s remote-first environment, online tools have changed how we work. They’ve made it easier than ever to create clean, visually compelling artefacts. But they’ve also nudged us toward valuing polish over progress.
Pre-COVID, service blueprints rarely looked “done.” They lived on walls, layered with post-its, insights, risky assumptions, and half-baked ideas. Teams stood around them (usually snacking on sweets), debating the big problems, challenging the evidence, and iterating in real time. They were messy spaces and they worked, not because they were complete, but because they were active.
A service blueprint is not a deliverable. It’s a snapshot. And snapshots age quickly.
The AS-IS state you map today begins to drift the moment it’s captured. Customers change, internal processes shift, policy gets updated, priorities move. What felt accurate last month can already be out of date. Yet many teams still treat blueprints as static artefacts to be finalised, signed off, and filed away. This is where they lose their value.
For leadership, this presents a subtle but important shift in how we evaluate good practice, because the real value of a blueprint isn’t in how it looks. It’s in how blueprinting is done.
The question is not: “Have we got a beautiful finished blueprint?”
But: “Are my teams blueprinting collaboratively to help them think, decide, and act?”
Does it bring the right people into the conversation?
Does it expose gaps, tensions, and opportunities?
Does it support better decision-making?
Does it evolve as the service evolves?
If the answer is yes, then it’s doing its job.
For practitioners, especially those earlier in their careers, there’s often pressure to quickly produce something “complete”. I recommend we reframe this to think of service blueprinting as a continuous and evolving practise.
A blueprint isn’t meant to be perfect. It’s meant to be useful.
That means being clear on:
The purpose of the map
Who needs to engage with it
What insights you’re trying to unlock
What decisions it needs to support
What problems it should help solve
Everything else is secondary.
The truth is, service design has never been about producing artefacts. It’s about creating clarity in complex, changing systems and that work is never really finished.